Add in a "verify" slash command to confirm signing keys #912

kscz · 2017-05-20T23:48:06Z

Allows users to send a text string via an alternative channel (like email
or SMS) which Riot can leverage to confirm that the signing keys match.

Effectively removes the tedium of checking keys until a better mechanism
is completed.

Note that this is dependent on matrix-org/matrix-js-sdk#439

matrixbot · 2017-05-20T23:48:08Z

Can one of the admins verify this patch?

kscz · 2017-05-20T23:54:20Z

Ack, messed up the error dialog in my hurry, one moment...

t3chguy · 2017-05-21T03:22:27Z

src/SlashCommands.js

+    // Verify a user, device, and pubkey tuple
+    verify: new Command("verify", "<userId> <deviceId> <deviceSigningKey>", function(room_id, args) {
+        if (args) {
+            var matches = args.match(/^(\S+) +(\S+) +(\S+)?$/);


not sure whether it'd be more sensible to use more specific character groups, since all 3 have specific grammars

Well, I guess I was trying to avoid having a complex regex considering all the information is checked against APIs which accept arbitrary strings. Is there any reason to make this more specific? Any recommendations?

If you want to go for that path then maybe simpler using String.prototype.split

FWIW the other code in this file follows this Regex approach to parse out inputs. Probably should be properly validated and sanitized, but that's kinda unrelated to this change.

t3chguy · 2017-05-21T03:26:02Z

src/SlashCommands.js

+                            </div>
+                        ),
+                        button: "Accept this validated key",
+                        onFinished: confirm=>{


should be onFinished: (confirm) => { to make ESLint happy :)

Will fix! Side note: you should also fix this in onVerifyClick in src/components/views/elements/DeviceVerifyButtons.js

t3chguy · 2017-05-21T03:26:37Z

src/SlashCommands.js

+                }
+            }
+        }
+        return reject(this.getUsage());
    })


add a trailing comma plox

t3chguy · 2017-05-21T03:27:00Z

src/SlashCommands.js

+                } else {
+                    return reject("WARNING: KEY VALIDATION FAILED! The signing key for " + userId + " and device "
+                            + deviceId + " is \"" + device.getFingerprint() + "\" which does not match the provided key \""
+                            + fingerprint + "\" This could mean your communications are being intercepted!");


maybe toy with template literals to make the string interpolation a little neater

Okay, I'll see if I can clean this up.

t3chguy · 2017-05-21T03:28:09Z

Test build deployed to: https://riot.ovh/builds/oob-verify-device/

t3chguy · 2017-05-21T03:38:24Z

Seeing Uncaught TypeError: r.promise.done is not a function in console after a verify, seems related

EDIT: fixed

midopa · 2017-05-21T04:16:58Z

src/SlashCommands.js

+    // Verify a user, device, and pubkey tuple
+    verify: new Command("verify", "<userId> <deviceId> <deviceSigningKey>", function(room_id, args) {
+        if (args) {
+            var matches = args.match(/^(\S+) +(\S+) +(\S+)?$/);


Shouldn't the last capture group (for deviceSigningKey) be mandatory? Otherwise, line 299 can get an undefined. And then line 301 would be comparing the device fingerprint against nothing. The call will fail, which is fine. But it seems odd to have a verify method with the actual verifiy datum optional.

Oh man, how did I miss that?! Yes, sorry, that is a terribly silly bug. Will fix.

midopa · 2017-05-21T04:21:51Z

src/SlashCommands.js

+
+                    var QuestionDialog = sdk.getComponent("dialogs.QuestionDialog");
+                    return success(Modal.createDialog(QuestionDialog, {
+                        title: "Approve Validated device",


Inconsistent casing?

~~Ah, sorry, this is a copy-paste induced casing problem. Will drop the 'Q' down to lowercase.~~
Derp. I mean I will drop the 'V' in "Validated" lowercase

Oh I meant the title. But yeah that too!

t3chguy requested that the Q in QuestionDialog remains capital to be consistent with other examples in this file (see ErrorDialog line 62, for example)

@kscz I think @midopa meant same as me, the V in validated should be lowercase :P

richvdh · 2017-05-22T08:42:17Z

src/components/views/elements/DeviceVerifyButtons.js

@@ -65,7 +65,8 @@ export default React.createClass({
                        <ul>
                            <li><label>Device name:</label> <span>{ this.state.device.getDisplayName() }</span></li>
                            <li><label>Device ID:</label>   <span><code>{ this.state.device.deviceId}</code></span></li>
-                            <li><label>Device key:</label>  <span><code><b>{ this.state.device.getFingerprint() }</b></code></span></li>
+                            <li><label>Device fingerprint:</label>  <span><code><b>{ this.state.device.getFingerprint() }</b></code></span></li>


I'm not against changing this, but we need to keep the Settings screen consistent, so that people know what they are supposed to be comparing.

I guess I find it confusing that we have different names for it different places. I'd prefer (in code) if we referred to them as "signing key" and something else (maybe "stream key"?). "Fingerprint" seems to imply that it's a partial key, or something one could use to quickly verify matches, not that it is our primary source of trust for this user.

Would you be opposed to me making a different PR with "fingerprint" replaced by "signing key" or something similar?

I pulled this because the refactoring of the verify device dialog made it a difficult merge anyway. I would like to have a longer discussion at some point about the "streaming key" at some point! As I pointed out in our chat a few weeks ago, I'm not terribly clear on why each user+device pairing doesn't have a unique streaming key (currently both keys are basically permanent).

Makes sense to keep it separate. Sorry for causing conflicts.

I agree that there is a bit of a naming confusion going on at the moment. "Signing key" and "encryption key" might be better terms, though tbh in the UI I would prefer the user to be able to forget there is more than one key.

richvdh · 2017-05-22T08:43:16Z

src/components/views/elements/DeviceVerifyButtons.js

@@ -65,7 +65,8 @@ export default React.createClass({
                        <ul>
                            <li><label>Device name:</label> <span>{ this.state.device.getDisplayName() }</span></li>
                            <li><label>Device ID:</label>   <span><code>{ this.state.device.deviceId}</code></span></li>
-                            <li><label>Device key:</label>  <span><code><b>{ this.state.device.getFingerprint() }</b></code></span></li>
+                            <li><label>Device fingerprint:</label>  <span><code><b>{ this.state.device.getFingerprint() }</b></code></span></li>
+                            <li><label>Device key:</label>  <span><code><b>{ this.state.device.getIdentityKey() }</b></code></span></li>


... and I'd prefer not to show this key at all - it's not useful for the verification process and I worry it will confuse people.

While it may not be useful at the moment, I wish there was somewhere that it was exposed to the user so they could see the other "public key" they trust. If someone's signing key was used to sign "0" as the streaming key, I would be concerned, and it's just odd that you can't find it in the UI (as far as I can tell).

Also removed in the merge.

richvdh · 2017-05-22T08:47:17Z

src/SlashCommands.js

+                                        <li><label>Device name:</label> <span>{ device.getDisplayName() }</span></li>
+                                        <li><label>Device ID:</label>   <span><code>{ device.deviceId}</code></span></li>
+                                        <li><label>Device fingerprint:</label>  <span><code><b>{ device.getFingerprint() }</b></code></span></li>
+                                        <li><label>Device key:</label>  <span><code><b>{ device.getIdentityKey() }</b></code></span></li>


again, no need for this.

richvdh · 2017-05-22T08:56:49Z

src/SlashCommands.js

+                } else {
+                    return reject(`WARNING: KEY VERIFICATION FAILED! The signing key for ${userId} and device
+                            ${deviceId} is "${device.getFingerprint()}" which does not match the provided key
+                            "${fingerprint}" This could mean your communications are being intercepted!`);


missing .

Ack, yes, good catch.

richvdh · 2017-05-22T09:01:02Z

src/SlashCommands.js

+                            <div>
+                                <p>
+                                    The signing key in your slash command matches the signing key you
+                                    received for this user and device!


The ! marks make this sound a bit overexcitable ;). Can you just use . please?

Ok!

... I mean "Ok."

richvdh · 2017-05-22T09:02:04Z

src/SlashCommands.js

+                                    </ul>
+                                </div>
+                                <p>
+                                    If you would like to accept this device as verified, press accept!


Given the text on the button is "Accept this verified key", I think this text is redundant.

richvdh · 2017-05-22T09:28:44Z

src/SlashCommands.js

+                        description: (
+                            <div>
+                                <p>
+                                    The signing key in your slash command matches the signing key you


I'm a bit undecided about whether we need a confirmation dialog here. I think that by the time you're pasting /verify commands in, it's up to you to have made sure that they've come from a trustworthy source - I'm not sure what purpose an extra confirmation serves here.

One obvious danger is that inexperienced users might be persuaded to c&p a /verify command from a malicious user. A better solution to that might be to pop up a dialog explaining what's going on the first time they run a /verify command (and store a flag so they don't have to do it each time).

My thought was along the lines of future applications: in this flow it's unlikely to matter, but in the future if this was invoked through some other mechanism, I would expect you just want a last-minute "hey, you intended to do this, didn't you?" I was basically assuming "in the future you might invoke this dialog through a QR code, and it shows you what's about to happen before it happens."

As I said in #riot-dev: if you haven't invoked this functionality via a slash-command, you may want a confirmation dialog. But in that case, the confirmation functionality doesn't belong in SlashCommands.js.

Allows users to send a text string via an alternative channel (like email or SMS) which Riot can leverage to confirm that the signing keys match. Effectively removes the tedium of checking keys until a better mechanism is completed. Signed-off-by: Kit Sczudlo <[email protected]>

Replace all instaces of "Validated" with "Verified", and error out when the user's device is already verified. Signed-off-by: Kit Sczudlo <[email protected]>

Signed-off-by: Kit Sczudlo <[email protected]>

Also remove a few unnecessary escape characters in front or double quotes Signed-off-by: Kit Sczudlo <[email protected]>

Signed-off-by: Kit Sczudlo <[email protected]>

richvdh · 2017-05-23T08:22:17Z

looks good, thanks!

Allows users to send a text string via an alternative channel (like email or SMS) which Riot can leverage to confirm that the signing keys match. Effectively removes the tedium of checking keys until a better mechanism is completed. Signed-off-by: Kit Sczudlo <[email protected]>

richvdh · 2017-05-23T08:25:20Z

merged as 26c8540

kscz force-pushed the add_verify branch 2 times, most recently from 9f3b2b5 to 9336642 Compare May 21, 2017 00:20

t3chguy reviewed May 21, 2017

View reviewed changes

t3chguy suggested changes May 21, 2017

View reviewed changes

midopa reviewed May 21, 2017

View reviewed changes

kscz force-pushed the add_verify branch from 9336642 to e006ef9 Compare May 21, 2017 08:08

t3chguy approved these changes May 21, 2017

View reviewed changes

t3chguy assigned lukebarnard1 May 21, 2017

richvdh assigned richvdh and unassigned lukebarnard1 May 22, 2017

richvdh reviewed May 22, 2017

View reviewed changes

kscz added 4 commits May 22, 2017 22:03

Make wording more consistent, notify user of edgecases

92ca3c2

Replace all instaces of "Validated" with "Verified", and error out when the user's device is already verified. Signed-off-by: Kit Sczudlo <[email protected]>

Fix nit to make if conditional more straightforward

6897c60

Signed-off-by: Kit Sczudlo <[email protected]>

Prefer const over var, replace validated with verified

4be5d88

Also remove a few unnecessary escape characters in front or double quotes Signed-off-by: Kit Sczudlo <[email protected]>

kscz force-pushed the add_verify branch from 1af7598 to 4be5d88 Compare May 23, 2017 05:05

Streamline "accept" dialog and fix missing period

352f81b

Signed-off-by: Kit Sczudlo <[email protected]>

kscz force-pushed the add_verify branch from 5b98c74 to 352f81b Compare May 23, 2017 06:32

kscz added 3 commits May 22, 2017 23:43

Fix missing space before username in verify dialog

68df4a8

Signed-off-by: Kit Sczudlo <[email protected]>

Change acceptance dialog to confirmation dialog

fbfbcc1

Signed-off-by: Kit Sczudlo <[email protected]>

Make the confirmation dialog after verification

97c98b1

Signed-off-by: Kit Sczudlo <[email protected]>

richvdh closed this May 23, 2017

kscz deleted the add_verify branch May 23, 2017 09:22

Add in a "verify" slash command to confirm signing keys #912

Add in a "verify" slash command to confirm signing keys #912

Conversation

kscz commented May 20, 2017 • edited Loading

matrixbot commented May 20, 2017

kscz commented May 20, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kscz May 21, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

t3chguy commented May 21, 2017

t3chguy commented May 21, 2017 • edited Loading

midopa May 21, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kscz May 21, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

richvdh commented May 23, 2017

richvdh commented May 23, 2017

kscz commented May 20, 2017 •

edited

Loading

kscz May 21, 2017 •

edited

Loading

t3chguy commented May 21, 2017 •

edited

Loading

midopa May 21, 2017 •

edited

Loading

kscz May 21, 2017 •

edited

Loading